Centro Federal de Educação Tecnológica de Minas Gerais

"O professor agente é um projeto porque ele é algo que possui um objetivo final / finalização, não é algo que será trabalhado por um período indeterminado e tem um custo fixo para a sua criação, ao contrário de uma operação."

"Sem sacrificar a qualidade, podemos diminuir o escopo do projeto e aumentar o tempo, que faria um projeto com menos features mas o aumento no tempo garantiria a qualidade, e também podemos diminuir o tempo e aumentar o custo, que significa fazer o projeto com a mesma qualidade, menos tempo mas maior custo."

"O ciclo de vida adotado foi criado pensando que cada aluno da equipe teria 4h por semana para o projeto, 8h por sprint e 40h no total em 5 sprints, a abordagem escolhida foi a híbrida, com a criação de todas as issues no começo do semestre mas com alterações sendo possíveis conforme o progresso do semestre."

Diagrama: Raiz [Professor Agente] com ramificações: [Integração com a plataforma], [Testes Socráticos], [Implementação no servidor]. Texto: "A EAP é hierárquica porque ela define objetivos compostos por partes menores de menor significância, mas quando se sobe na árvore a significância aumenta até chegar no projeto em si, criando uma hierarquia."

Issue 1: "Teste de conexão com a API inicial" (Desc: Conectar API do LLM com a plataforma; Critério: Ser possível ter uma conversa com a LLM a partir da plataforma; Est: 4h). Issue 2: "Testes contra Prompt Injection" (Est: 8h). Justificativa: "Como prompt injection é algo mais difícil e que leva mais tempo pra tratar do que a outra issue, ela recebe mais tempo."

"Milestones não substituem sprints por serem pacotes de trabalho mais longos, que raramente vão ser possíveis de serem feitos em 1 sprint, Kanban sem sprints pode ser adequado em um projeto onde todos os requisitos já foram levantados e não será necessário mudanças futuras, com todas as sprints pré-definidas."

"Definição de pronto é como o projeto considera o que é uma feature completa e integrada / o que é necessário para ir para a próxima issue, caso os testes de segurança sejam omitidos, a feature feita não vai estar pronta, que nesse caso seria o chat."

"(c) é o mais caro porque um erro de segurança encontrado por um aluno pode gerar processos com custos exorbitantes, seguido por (d) que impede o usuário de usar o software completamente, (a) que gasta tempo de outros devs e (b) que gasta apenas o tempo de 1 dev."

"A regra 1:10:100 diz que o custo é 1 quando o erro é encontrado pelo dev, 10 quando é encontrado na hora do deploy e 100 quando o usuário encontra um bug no sistema, em softwares que usam IA, colocar testes de segurança para evitar que um usuário gaste tokens à vontade ou quebre as regras da IA para ter acesso irrestrito a API pode salvar muito dinheiro, bem mais do que foi gasto implementando os testes de segurança."

Posicionamento: Impacto Alto e Probabilidade Baixa (quadrante inferior direito). Texto: "Esse evento era um risco que se tornou um problema por ter apenas uma chance de acontecer e era baseado na responsabilidade de um dev. O risco tinha uma probabilidade bem baixa de acontecer, por ser algo facilmente evitável, mas tem um impacto enorme gerando possíveis custos grandes."

"Desativar aquela chave, deletar o commit e atualizar o histórico, clonar o repositório em um novo sem o leak. Uma ação preventiva seria, além de adicionar no .gitignore o arquivo com as chaves, efetuar uma rotação constante das chaves de API."

Risco de entrada: "Uso exacerbado de Tokens" (Causa: Falta de limitação; P: Baixa; I: Alto; Mitigação: Rate limit; Contingência: Limite por IP). [Risco de saída: Omitido]. Documentação: "Um ADR seria a melhor escolha, por ser feito justamente para documentar issues."

"Uma comunicação síncrona permite uma discussão mais fluida, onde é fácil descobrir problemas e discutir ideias, portanto documentar essas conversas é uma tarefa difícil, exigindo muitas vezes alguém na reunião ficar apenas por conta disso. Já a assíncrona a documentação já vem pronta, que é o histórico, mas perde na fluidez e facilidade de discutir ideias; o project charter é aonde é documentado as decisões técnicas do projeto, por ser feito no início e algo que é difícil de ser modificado."

Matriz: Provedor em 'Manter satisfeito'; Professor e Equipe em 'Gerenciar de perto'; Alunos em 'Monitorar'; Coordenação em 'Manter informado'. Texto: "Para essa comunicação específica dos dois stakeholders mais críticos, que é o professor e os alunos, a própria aula semanal sobre a matéria seria o momento perfeito para se discutir sobre o projeto, dado que o conteúdo da aula é a matéria de GPS onde discutimos esse tipo de coisa."

"Uma abordagem escolhida seria a de respostas curtas, porque além de salvar tokens que é economizar, algo que seria gasto em excesso em respostas mais longas, a chance do modelo alucinar é bem mais baixo, por não ter que criar uma frase de resposta longa para algo que é simples e objetivo, e por causa da urgência do projeto, tratar esses riscos já aumentaria o custo do projeto sem aumentar a qualidade, e ainda adicionaria riscos maiores ao projeto, como a alucinação."